hi3516cv300: load_hisilicon — insmod hi_osal.ko in CMA branch too (closes #2061)#2105
Merged
Merged
Conversation
Fix issue #2061. insert_osal() picks between the hisi-allocator and the cma-allocator init paths based on whether the kernel cmdline passes mmz=. Both paths are served by the same cv300 OSAL module (open_osal renamed to hi_osal.ko on install by hisilicon-opensdk; mmz_allocator= is a module parameter, not a separate module). The script tried to insmod a cma_osal.ko that no recipe builds: insmod: can't insert 'cma_osal.ko': No such file or directory ******* Error: There's something wrong, please check! ***** Hidden until #2059 / #2060 because load_hisilicon used to bail at the os_mem= guard before ever reaching insert_osal. Post-#2060 the guard is correct and the cma branch runs whenever the bootloader passes mmz=… (qemu-hisilicon, modern U-Boot setups) — zero modules load, majestic comes up with no /dev/mmz. Mirrors how cv500's load_hisilicon already calls the same module on both branches with just the mmz_allocator= arg differing. Closes #2061.
2 tasks
widgetii
added a commit
to OpenIPC/openhisilicon
that referenced
this pull request
May 17, 2026
) cv500: the original cma_osal.ko-missing bug (#2062) was fixed long ago — load_hisilicon uses `modprobe open_osal` in both branches now. The qemu-boot row already passes the (permissive) assertion gate even though only 1 HISI module loads under the current QEMU bootargs. Drop the allow-failure marker so a real cv500 regression in future turns the row red instead of being silently masked. cv300: OpenIPC/firmware#2105 fixed the cma_osal.ko reference in load_hisilicon, but qemu-hisilicon's hi3516cv300 machine model appends `mmz_allocator=hisi mmz=…,96M` unconditionally, while the cv300_lite kernel ships with `# CONFIG_CMA is not set`. The script sees mmz= in /proc/cmdline → takes the cma allocator branch → hi_osal.ko CMA init fails silently → script hangs at "Error: environment not initialized" before the lsmod probe runs. Real cv300 cameras don't pass mmz= in bootargs and always take the hisi branch (verified on openipc-hi3516cv300.dlab.torturelabs.com: `mem=32M console=ttyAMA0,115200 panic=20 root=/dev/mtdblock3 ...` — no mmz=, lsmod shows 34 HiSi modules). Keep cv300's allow-failure pending either: - a qemu-hisilicon bootargs fix (drop mmz= for cv300 to match real boards), or - cv300 CMA kernel config flip + a CMA-capable cv300 build. Updated comments to reflect the actual blocker (was: "needs firmware fix"; now: "firmware fixed, blocked on QEMU bootargs mismatch"). Co-authored-by: Vasiliy Yakovlev <vixand@openipc.org>
widgetii
added a commit
to OpenIPC/openhisilicon
that referenced
this pull request
May 17, 2026
Two upstream fixes unblock the cv300 qemu-boot row: - OpenIPC/firmware#2105: load_hisilicon now uses hi_osal.ko in both branches (was: cma_osal.ko, which the firmware never builds). - widgetii/qemu-hisilicon#101 / commit 42dea48a: hi3516cv300 machine model no longer appends `mmz=…` to bootargs, matching real V3 board u-boot env. The script now takes the hisi allocator branch as it always did on real hardware. Local QEMU boot with both fixes in place loads 31 HISI modules (vs 34 on real openipc-hi3516cv300.dlab.torturelabs.com hardware) and reaches the login prompt with no Oops/panic/BUG/Trace. Drop the allow-failure marker and gate on min_modules=20 (well below the observed 31, with margin for benign drift). Issue body of #2061 marked this CI hardcoding as the final cleanup step; this is it. Co-authored-by: Vasiliy Yakovlev <vixand@openipc.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
`insert_osal()` picks between the hisi-allocator and the cma-allocator init paths based on whether the kernel cmdline passes `mmz=`. Both paths are served by the same cv300 OSAL module (`open_osal.ko` renamed to `hi_osal.ko` on install by hisilicon-opensdk; `mmz_allocator=` is a module parameter, not a separate module). The script tried to insmod a `cma_osal.ko` that no recipe builds:
```
insmod: can't insert 'cma_osal.ko': No such file or directory
******* Error: There's something wrong, please check! *****
```
Hidden until #2059 / #2060 because `load_hisilicon` used to bail at the `os_mem=` guard before ever reaching `insert_osal`. Post-#2060 the guard is correct and the cma branch runs whenever the bootloader passes `mmz=…` (qemu-hisilicon, modern U-Boot setups) — zero modules load, majestic comes up with no `/dev/mmz`.
This PR is the 1-line "Option 1" fix from the issue. Mirrors how cv500's `load_hisilicon` already calls the same module on both branches with just the `mmz_allocator=` arg differing.
Closes #2061.
Test plan